Appl. No. 09/903,991 

Reply to Office Action of: January 13, 2006 
REMARKS 

Applicant wishes to thank the Examiner for reviewing the present application. 

Amendments to the Specification 

The website address in paragraph [0026] has been replaced with the more generic term 
"web site" in order to avoid the website address becoming a hyperlink when entered. No new 
subject matter is added by way of this amendment. 

Claim Amendments 

Claim 1 is amended to clarify the nature of the steps recited therein and to indicate that 
the request is modified by replacing an address of the DNS of the ISP, which was part of the 
subject matter of previous claim 12. Claim 12 is amended accordingly. 

Claim 13's dependency is changed in light of the cancellation of claim 12. 

Claim 17 is amended according to the amendments made to claim 1 . 

No new subject matter is believed to have been added by way of these amendments. 

Objections to the Specification 

The disclosure has been objected to for including an embedded hyperlink. Applicant 
notes that in order to remove the website address and re-enter same (as previously attempted) the 
address must be underlined. Since underlining a website address in a word processor effectively 
converts the address to a hyperlink, and to prevent this from occurring yet again, Applicant has 
replaced the specific address recited in paragraph [0026] with more general terminology. 
Applicant believes that such amendment overcomes the Examiner's objection. 

Claim Rejections 

Claims 1, 4 and 12-19 have been rejected under 35 U.S. C. § 102(e) as being anticipated 
by U.S. Patent No. 6,832,322 to Boden et al. Applicant respectfully traverses the rejections as 
follows. 

The present application relates to a system and method for transparently resolving a web 
site address for a public host when the public host is connected to a virtual private network. The 
public host includes a software module that monitors, intercepts and routes domain name 
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requests and subsequent responses without the public host knowing that such an operation is 
occurring, i.e. transparent thereto. 

This "interception" is performed at the host i.e., communication packets outbound from 
the host toward the gateway are intercepted, operated on and then routed without the public host 
knowing. Claim 1 has been amended to clarify the transparency of the software module to the 
public host. Such transparency is particularly useful where the system parameters of the public 
host are not alterable, e.g., where the public host will only receive address locations from the ISP 
DNS (e.g. see page 4, lines 14-23). In the present application, when the public host is connected 
to a VPN, it is also able to receive address locations from the VPN DNS while thinking that it is 
receiving address locations from the DNS of the ISP. 

Claim 1 , as amended, specifies that the modification of the requests outbound of the 
public host occurs by the software module replacing an address of the ISP DNS with the address 
of the DNS of the VPN. The DNS of the VPN may then resolve the request and return a domain 
name response. In order to fool the public host into thinking that it is receiving an address 
location from the DNS of the ISP, the software module also modifies inbound responses to 
counter-act the address modification. The software module operates to transparently route 
domain name requests in a host-to-gateway connection. 

Boden teaches a system for integrating network address translation (NAT) with internet 
protocol (IP) security. Security is provided in a VPN by performing one or a combination of 
four types of VPN NAT. This procedure involves dynamically generating NAT rules and 
associating them with the manual or dynamically generated security associations before 
beginning IP security that uses the security associations. As IP Sec is performed on outbound 
and inbound datagrams, the NAT function is also performed on a gateway-to-gateway 
connection. Boden is concerned with avoiding duplication of the DNS entries on DNS servers 
and to avoid possible conflicts with IP addresses (overlapping address domains). 

Boden does not teach transparent routing on a host-to-gateway connection but rather 
operates purely at a gateway-to-gateway connection. The user (host) is at all time aware (and in 
fact participates in configuring) NAT occurs. 

Applicant refers to column 5, lines 64-67, which clearly shows that in Boden, the NAT 
operations are not transparent to the host (user) but in fact are configured by the users 
themselves: "In step 20, the user decides on and configures the connections that will require 
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NAT. This is logically equivalent to writing NAT rules. The four cases to be considered in 
doing so are depicted in Table 1 ." As noted above, claim 1 has been amended to more clearly 
express that the software module is included in (i.e. at host) and operates transparent to the 
public host, which is believed to further clarify this distinction over Boden. 

Therefore, Boden does not teach a software module at the public host transparently 
intercepting and modifying domain name requests but rather teaches NAT in a gateway-to- 
gateway connection and the user actually actively participates in configuring the NAT rules. 
For at least this reason, Boden does not teach every element of claim 1 and, as such clearly 
cannot anticipate. 

As noted above, claim 1 is also amended to specify how the software module modifies 
the request, namely by replacing an ISP DNS address with a VPN DNS address, previously part 
of claim 12. Applicant respectfully submits that Boden does not teach such a step and thus 
cannot anticipate. 

The Examiner relies on column 6, line 60 to column 7, line 36 in support of teaching the 
subject matter of previous claim 12. However, upon a careful review of this passage, Applicant 
cannot determine where in Boden the Examiner has located such a step. If anything, Boden 
teaches a gateway replacing an address, i.e., during NAT. 

Applicant respectfully submits that Boden does not teach a software module at the public 
host modifying a domain name request as claimed. Therefore, for at least this reason, Applicant 
believes that Boden cannot anticipate amended claim 1 . 

As shown above, Applicant believes that the amendments made to claim 1 serve to 
clarify the distinctions over Boden. In particular, where claim 1 is concerned with transparently 
routing domain name requests in a host-to-gateway connection, Boden in fact has the host 
participate in configuring NAT rules. Further, where claim 1 includes a step of the software 
module at the public host modifying an address in the request, Boden is entirely silent in that 
regard and at most teaches a visible address modification at the gateway . Therefore, Applicant 
believes that amended claim 1 clearly distinguishes over Boden and that the rejections under 35 
U.S.C. 102(e) are improper. 

Summary 

In view of the foregoing, Applicant respectfully believes that all of the Examiner's 
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objections and rejections have been successfully traversed and that all pending claims, namely 
claims 1, 4 and 13-19 distinguish over Boden and are in condition for allowance. 

Applicant requests early reconsideration and allowance of the present application. 

Respectfully submitted, 
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